The present invention relates to the field of data unit communication. In a data unit communication, an amount of data is divided into a sequence of data parts, and these data parts are sent over a connection from a sender to a receiver, where the amount of data is re-assembled from the data parts. In the context of different technologies and protocols, such data parts carry different names, such as segment, cell, frame, protocol data unit, etc. The term “data unit” generically relates to any such data part used in communication.
In data unit communication, one problem is that of reliable transport, because data units can become lost or corrupted during transport. To solve this problem, it is known to send feedback messages from a data unit receiver to a data unit sender, where the feedback messages contain receive information on data units that arrived at the data unit receiver. The data units are identified by means of sequence position identifiers that identify the position of each data unit in the overall sequence. The receive information can be of various kind, e.g. can indicate a correct receipt or an incorrect receipt (which includes no receipt at all). The data unit sender can then appropriately conduct retransmissions of data units that were not correctly received at the data unit receiver. A well known example of such a feedback mechanism is Automatic Retransmission reQuest (ARQ), e.g. as used in the Transmission Control Protocol (TCP).
Another aspect of data unit communication is that of flow control. A flow control procedure is for controlling how much data that can be sent at a given time. The challenge in flow control lies in adjusting the data rate correctly, in such a way that the connection is efficiently utilized. Namely, if too little data is sent in a given period of time (i.e. the capacity of the network between sender and receiver could carry more data), then the through-put is suboptimal, and if too much data is sent in a given period of time, the network is overburdened and data unit losses result. Data unit losses due to overburdening are also referred to as congestion. As a consequence, flow control procedures often comprise a response mechanism for avoiding or reducing congestion in the connected network, in response to detecting an event that indicates a possible loss of a data unit or to receiving an indication of congestion. Such a response mechanism may comprise changing the value of a data rate limitation parameter towards a smaller data rate. As an example, in the well-known window based flow control scheme, such a data rate limitation parameter can be a window that defines how many unacknowledged data units may be sent at a given time (like the congestion window cwnd of TCP), and the response to congestion can then consist in reducing this window.
Flow control procedures may also rely on the receive information in feedback messages. For example, in TCP the congestion window cwnd is increased in response to receiving a cumulative acknowledgment from the receiver that indicates a new sequence position identifier. A cumulative acknowledgment or ACK identifies the last data unit correctly received at the receiver that has the highest in-sequence sequence position indicator of all data units received there. This shown in FIG. 2 on the left hand side. In other words, it identifies the sequence position identifier most advanced in the sequence, for which a data unit was correctly received and below which there are no gaps in the sequence. On the other hand, if three duplicate cumulative acknowledgments are received, then the congestion window is reduced.
Although both flow control and retransmission control may use receive information from feedback messages, flow control and retransmission control are two independent and unrelated aspects of a data unit transmission. Retransmission control deals with reliable transmission, whereas flow control deals with efficient network utilization.
As already mentioned, a TCP receiver sends cumulative acknowledgements (ACKs) for data that has been received in the correct order. Upon correct reception of the expected (in-order) segment the receiver sends a cumulative acknowledgement towards the sender. Once the ACK is received at the sender it will advance the lower and upper window edge which allows the sender to transmit new data unit(s). According to the TCP congestion control algorithm the received ACK will furthermore increase the congestion window so that more data can be in flight.
TCP is known to provide a so-called selective acknowledgment (SACK) mechanism. If the receiver detects losses (e.g. it receives out-of-order data units, i.e. not the data unit with the next expected sequence position identifier, but data units with higher sequence position identifiers, see right hand side of FIG. 2), it adds a SACK (selective acknowledgement) block to the TCP ACK. When the sender decides to perform error recovery it sends a retransmission of the negatively acknowledged segments. Furthermore, it decreases the size of the congestion window as it assumes that the loss was caused by congestion, i.e., by too much data traversing the network.
According to TCP, the selective acknowledgement (SACK) does not allow the sender to finally remove the corresponding segments from its window as the receiver might not be able to deliver these bytes to the higher layer (application). By definition, it acknowledges a data block that was received out-of-order, i.e., there is a gap in the data-stream.
The round-trip-time (RTT), which indicates the time that passes between the sending of a given data unit and the receipt of a feedback message relating to the given data unit, has a large impact on the performance of TCP's congestion control algorithm, as the sender has to wait for ACKs before being allowed to send new data. In general, the performance of flow control procedures that make use of receive information will depend on the delay between sending a data unit and the receipt of a corresponding feedback message. The problem becomes stronger over long connections, e.g. connections in which the data units are sent from the sender to the receiver over one or more intermediate points.
It is known to use proxies to enhance the performance of TCP connections (in particular in case of links with high bandwidth and large delays). TCP proxies may use split connection approaches i.e. a connection between an ultimate sender and an ultimate receiver is split and the proxy establishes and maintains two separate connections (one to the sender and one to the receiver). The main drawback is that the end-to-end principle is violated. An ACK received by the sender does not confirm successful delivery to the destination but only to the proxy. If the proxy fails in delivering the data towards the receiver (or to the next proxy) already acknowledged data may never reach its final destination. In general, split-connection-proxies can not join or leave an ongoing connection.
With regard to retransmission control over a connection from a sender to a receiver via one or more relay points, a mechanism referred to as Relay ARQ has been proposed in patent application PCT/EP2004/009967, the contents of which are herewith incorporated by reference. An important feature of Relay ARQ is that it establishes a single connection in which a common protocol state is shared between the end nodes and all relay nodes. The protocol state maintained in relay nodes is a soft-state, which allows relay nodes to seamlessly “leave and join” without breaking the Relay ARQ connection. An important aspect behind Relay ARQ is the concept of Relay-Acknowledgements (RACKs). A relay node sends a RACK towards its sending peer to indicate that it has correctly received a data unit. On receiving a RACK, the sending peer may temporarily delegate the retransmission responsibility to the relay node. Besides this first type of receive information that indicates the correct receipt at a relay node, there is also a second type of receive information that indicates a correct receipt at the receiving end-node. Each relay node forwards the second type receive information towards the sending end-node. The ultimate retransmission responsibility should remain with the sending end-node until the receiving end-node acknowledges the successful delivery of the data unit with the second type receive information, i.e. until the sending end-node receives the second type receive information.